<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>LXC</title>
<link rel="stylesheet" type="text/css" href="../C.css">
<script type="text/javascript" src="../jquery.js"></script><script type="text/javascript" src="../jquery.syntax.js"></script><script type="text/javascript" src="../yelp.js"></script>
</head>
<body id="home">
<!--<script src="https://ssl.google-analytics.com/urchin.js" type="text/javascript"></script><script type="text/javascript">
        _uacct = "UA-1018242-8";
        urchinTracker();
      </script><script>
      function englishPageVersion() {
        var href = window.location.href;
        if (href.slice(-1) == "/") {
                window.location = "index.html.en";
        } else {
                window.location = href.replace(/\.html.*/, ".html.en");
        }
         return false;
      }
      function browserPreferredLanguage() {
        var href = window.location.href;
        if (href.slice(-1) == "/") {
                window.location = href;
        } else {
                window.location = href.replace(/\.html.*/, ".html");
        }
        return false;
      }
      </script>--><div id="container">
<div id="container-inner">
<div id="mothership"><ul>
<li><a href="https://partners.ubuntu.com">Partners</a></li>
<li><a href="https://www.ubuntu.com/support/community-support">Support</a></li>
<li><a href="https://community.ubuntu.com">Community</a></li>
<li><a href="https://www.ubuntu.com">Ubuntu.com</a></li>
</ul></div>
<div id="header">
<h1 id="ubuntu-header"><a href="https://help.ubuntu.com/">Ubuntu Documentation</a></h1>
<ul id="main-menu">
<li><a class="main-menu-item current" href="https://help.ubuntu.com/">Official Documentation</a></li>
<li><a href="https://help.ubuntu.com/community/CommunityHelpWiki">Community Help Wiki</a></li>
<li><a href="https://community.ubuntu.com/t/contribute/26">Contribute</a></li>
</ul>
</div>
<div id="menu-search"><div id="search-box">
<noscript><form action="https://www.google.com/cse" id="cse-search-box"><div>
<input type="hidden" name="cx" value="003883529982892832976:e2vwumte3fq"><input type="hidden" name="ie" value="UTF-8"><input type="text" name="q" size="21"><input type="submit" name="sa" value="Search">
</div></form></noscript><!--
<script>
                document.write('<form action="https://help.ubuntu.com/search.html" id="cse-search-box">');
                document.write('  <div>');
                document.write('    <input type="hidden" name="cof" value="FORID:9">');
                document.write('    <input type="hidden" name="cx" value="003883529982892832976:e2vwumte3fq">');
                document.write('    <input type="hidden" name="ie" value="UTF-8">');
                document.write('    <input type="text" name="q" size="21">');
                document.write('    <input type="submit" name="sa" value="Search">');
                document.write('  </div>');
                document.write('</form>');
              </script>-->
</div></div>
<div class="trails"><div class="trail">
<a href="https://help.ubuntu.com/18.04" class="trail">Ubuntu 18.04</a> » <a class="trail" href="../index.html" title="Ubuntu Server Guide">Ubuntu Server Guide</a> » <a class="trail" href="virtualization.html" title="Virtualization">Virtualization</a> » </div></div>
<div id="cwt-content" class="clearfix content-area"><div id="page">
<div id="content">
<div class="links nextlinks">
<a class="nextlinks-prev" href="lxd.html" title="LXD">Previous</a><a class="nextlinks-next" href="../clustering/clustering.html" title="Clustering">Next</a>
</div>
<div class="hgroup"><h1 class="title">LXC</h1></div>
<div class="region">
<div class="contents">
<p class="para">Containers are a lightweight virtualization technology. They are
    more akin to an enhanced chroot than to full virtualization like Qemu or
    VMware, both because they do not emulate hardware and because containers
    share the same operating system as the host. Containers are
    similar to Solaris zones or BSD jails. Linux-vserver and OpenVZ
    are two pre-existing, independently developed implementations of
    containers-like functionality for Linux. In fact, containers came about as
    a result of the work to upstream the vserver and OpenVZ functionality.
    </p>
<p class="para">There are two user-space implementations of containers, each
    exploiting the same kernel features. Libvirt allows the use of containers
    through the LXC driver by connecting to 'lxc:///'. This can be very
    convenient as it supports the same usage as its other drivers. The other
    implementation, called simply 'LXC', is not compatible with libvirt, but
    is more flexible with more userspace tools. It is possible to switch
    between the two, though there are peculiarities which can cause
    confusion.</p>
<p class="para">In this document we will mainly describe the
    <span class="app application">lxc</span> package. Use of libvirt-lxc is not
    generally recommended due to a lack of Apparmor protection for
    libvirt-lxc containers.</p>
<p class="para">In this document, a container name will be shown as CN, C1, or
    C2.</p>
</div>
<div class="links sectionlinks" role="navigation"><ul>
<li class="links"><a class="xref" href="lxc.html#lxc-installation" title="Installation">Installation</a></li>
<li class="links"><a class="xref" href="lxc.html#lxc-basic-usage" title="Basic usage">Basic usage</a></li>
<li class="links"><a class="xref" href="lxc.html#lxc-global-conf" title="Global configuration">Global configuration</a></li>
<li class="links"><a class="xref" href="lxc.html#lxc-network" title="Networking">Networking</a></li>
<li class="links"><a class="xref" href="lxc.html#lxc-startup" title="LXC startup">LXC startup</a></li>
<li class="links"><a class="xref" href="lxc.html#lxc-backinstores" title="Backing Stores">Backing Stores</a></li>
<li class="links"><a class="xref" href="lxc.html#lxc-templates" title="Templates">Templates</a></li>
<li class="links"><a class="xref" href="lxc.html#lxc-autostart" title="Autostart">Autostart</a></li>
<li class="links"><a class="xref" href="lxc.html#lxc-apparmor" title="Apparmor">Apparmor</a></li>
<li class="links"><a class="xref" href="lxc.html#lxc-cgroups" title="Control Groups">Control Groups</a></li>
<li class="links"><a class="xref" href="lxc.html#lxc-cloning" title="Cloning">Cloning</a></li>
<li class="links"><a class="xref" href="lxc.html#lxc-hooks" title="Lifecycle management hooks">Lifecycle management hooks</a></li>
<li class="links"><a class="xref" href="lxc.html#lxc-consoles" title="Consoles">Consoles</a></li>
<li class="links"><a class="xref" href="lxc.html#lxc-debugging" title="Troubleshooting">Troubleshooting</a></li>
<li class="links"><a class="xref" href="lxc.html#python-lxc" title="LXC API">LXC API</a></li>
<li class="links"><a class="xref" href="lxc.html#lxc-security" title="Security">Security</a></li>
<li class="links"><a class="xref" href="lxc.html#lxc-resources" title="Resources">Resources</a></li>
</ul></div>
<div class="sect2 sect" id="lxc-installation"><div class="inner">
<div class="hgroup"><h2 class="title">Installation</h2></div>
<div class="region"><div class="contents">
<p class="para">The <span class="app application">lxc</span> package can be installed
      using</p>
<div class="screen"><pre class="contents "><span class="cmd command">
sudo apt install lxc
</span>
</pre></div>
<p class="para">This will pull in the required and recommended dependencies,
      as well as set up a network bridge for containers to use.  If you
      wish to use unprivileged containers, you will need to ensure that
      users have sufficient allocated subuids and subgids, and will likely
      want to allow users to connect containers to a bridge (see
      <a class="xref" href="lxc.html#lxc-unpriv" title="Basic unprivileged usage">Basic unprivileged usage</a>).
      </p>
</div></div>
</div></div>
<div class="sect2 sect" id="lxc-basic-usage"><div class="inner">
<div class="hgroup"><h2 class="title">Basic usage</h2></div>
<div class="region">
<div class="contents"><p class="para">
      LXC can be used in two distinct ways - privileged, by running the
      lxc commands as the root user;  or unprivileged, by running the
      lxc commands as a non-root user.  (The starting of unprivileged
      containers by the root user is possible, but not described here.)
      Unprivileged containers are more limited, for instance being unable
      to create device nodes or mount block-backed filesystems.  However
      they are less dangerous to the host, as the root userid in the
      container is mapped to a non-root userid on the host.
      </p></div>
<div class="sect3 sect"><div class="inner">
<div class="hgroup"><h3 class="title">Basic privileged usage</h3></div>
<div class="region"><div class="contents">
<p class="para">
      To create a privileged container, you can simply do:
      </p>
<div class="screen"><pre class="contents "><span class="cmd command">
sudo lxc-create --template download --name u1
</span>
or, abbreviated
<span class="cmd command">
sudo lxc-create -t download -n u1
</span>
</pre></div>
<p class="para">
      This will interactively ask for a container root filesystem type
      to download - in particular the distribution, release, and
      architecture.  To create the container non-interactively, you can
      specify these values on the command line:
      </p>
<div class="screen"><pre class="contents "><span class="cmd command">
sudo lxc-create -t download -n u1 -- --dist ubuntu --release bionic --arch amd64
</span>
or
<span class="cmd command">
sudo lxc-create -t download -n u1 -- -d ubuntu -r bionic -a amd64
</span>
</pre></div>
<p class="para">
      You can now use <span class="cmd command">lxc-ls</span> to list containers,
      <span class="cmd command">lxc-info</span> to obtain detailed container information,
      <span class="cmd command">lxc-start</span> to start and <span class="cmd command">lxc-stop</span>
      to stop the container.  <span class="cmd command">lxc-attach</span> and
      <span class="cmd command">lxc-console</span> allow you to enter a container, if
      ssh is not an option.  <span class="cmd command">lxc-destroy</span> removes the
      container, including its rootfs.  See the manual pages for more
      information on each command.  An example session might look like:
      </p>
<div class="screen"><pre class="contents "><span class="cmd command">
sudo lxc-ls --fancy
sudo lxc-start --name u1 --daemon
sudo lxc-info --name u1
sudo lxc-stop --name u1
sudo lxc-destroy --name u1
</span>
</pre></div>
</div></div>
</div></div>
<div class="sect3 sect"><div class="inner">
<div class="hgroup"><h3 class="title">User namespaces</h3></div>
<div class="region"><div class="contents">
<p class="para">
      Unprivileged containers allow users to create and administer
      containers without having any root privilege.  The feature
      underpinning this is called user namespaces.  User namespaces
      are hierarchical, with privileged tasks in a parent namespace
      being able to map its ids into child namespaces.  By default every
      task on the host runs in the initial user namespace, where
      the full range of ids is mapped onto the full range.  This can be
      seen by looking at /proc/self/uid_map and /proc/self/gid_map,
      which both will show "0 0 4294967295" when read from the initial
      user namespace.  As of Ubuntu 14.04, when new users are created
      they are by default offered a range of userids.
      The list of assigned ids can be seen in the files
      <span class="file filename">/etc/subuid</span> and <span class="file filename">/etc/subgid</span>
      See their respective manpages for more information.  Subuids and
      subgids are by convention started at id 100000 to avoid conflicting
      with system users.
      </p>
<p class="para">
      If a user was created on an earlier release, it can be granted a
      range of ids using <span class="cmd command">usermod</span>, as follows:
      </p>
<div class="screen"><pre class="contents "><span class="cmd command">
sudo usermod -v 100000-200000 -w 100000-200000 user1
</span>
</pre></div>
<p class="para">
        The programs <span class="cmd command">newuidmap</span> and <span class="cmd command">
	newgidmap</span> are setuid-root programs in the <span class="file filename">uidmap</span>
	package, which are used internally by lxc to map subuids and subgids
	from the host into the unprivileged container.  They ensure that
	the user only maps ids which are authorized by the host
	configuration.
      </p>
</div></div>
</div></div>
<div class="sect3 sect" id="lxc-unpriv"><div class="inner">
<div class="hgroup"><h3 class="title">Basic unprivileged usage</h3></div>
<div class="region"><div class="contents">
<p class="para">
      </p>
<p class="para">
      To create unprivileged containers, a few first steps are needed.  You
      will need to create a default container configuration file, specifying
      your desired id mappings and network setup, as well as configure the
      host to allow the unprivileged user to hook into the host network.  The
      example below assumes that your mapped user and group id ranges are
      100000-165536. Check your actual user and group id ranges and modify
      the example accordingly:
      </p>
<div class="screen"><pre class="contents "><span class="cmd command">
grep $USER /etc/subuid
grep $USER /etc/subgid
</span>
</pre></div>
<div class="screen"><pre class="contents "><span class="cmd command">
mkdir -p ~/.config/lxc
echo "lxc.id_map = u 0 100000 65536" &gt; ~/.config/lxc/default.conf
echo "lxc.id_map = g 0 100000 65536" &gt;&gt; ~/.config/lxc/default.conf
echo "lxc.network.type = veth" &gt;&gt; ~/.config/lxc/default.conf
echo "lxc.network.link = lxcbr0" &gt;&gt; ~/.config/lxc/default.conf
echo "$USER veth lxcbr0 2" | sudo tee -a /etc/lxc/lxc-usernet
</span>
</pre></div>
<p class="para">
      After this, you can create unprivileged containers the same way as
      privileged ones, simply without using sudo.
    </p>
<div class="screen"><pre class="contents "><span class="cmd command">
lxc-create -t download -n u1 -- -d ubuntu -r bionic -a amd64
lxc-start -n u1 -d
lxc-attach -n u1
lxc-stop -n u1
lxc-destroy -n u1
</span>
</pre></div>
</div></div>
</div></div>
<div class="sect3 sect" id="lxc-nesting"><div class="inner">
<div class="hgroup"><h3 class="title">Nesting</h3></div>
<div class="region"><div class="contents"><p class="para">In order to run containers inside containers - referred
	to as nested containers - two lines must be present in the
	parent container configuration file:
<div class="screen"><pre class="contents ">lxc.mount.auto = cgroup
lxc.aa_profile = lxc-container-default-with-nesting
</pre></div>
	The first will cause the cgroup manager socket to be bound
	into the container, so that lxc inside the container is able
	to administer cgroups for its nested containers.  The second
	causes the container to run in a looser Apparmor policy which
	allows the container to do the mounting required for starting
	containers.  Note that this policy, when used with a privileged
	container, is much less safe than the regular policy or an
	unprivileged container.  See <a class="xref" href="lxc.html#lxc-apparmor" title="Apparmor">Apparmor</a> for
	more information.
	</p></div></div>
</div></div>
</div>
</div></div>
<div class="sect2 sect" id="lxc-global-conf"><div class="inner">
<div class="hgroup"><h2 class="title">Global configuration</h2></div>
<div class="region"><div class="contents">
<p class="para">
      The following configuration files are consulted by LXC.  For
      privileged use, they are found under <span class="file filename">/etc/lxc</span>,
      while for unprivileged use they are under <span class="file filename">~/.config/lxc</span>.
      <div class="list itemizedlist"><ul class="list itemizedlist">
<li class="list itemizedlist">
	  <p class="para"><span class="file filename">lxc.conf</span> may optionally specify alternate
	  values for several lxc settings, including the lxcpath,
	  the default configuration, cgroups to use, a cgroup creation pattern,
	  and storage backend settings for lvm and zfs.</p>
	</li>
<li class="list itemizedlist">
	  <p class="para"><span class="file filename">default.conf</span> specifies configuration which
	  every newly created container should contain.  This usually contains
	  at least a network section, and, for unprivileged users, an id mapping
	  section</p>
	</li>
<li class="list itemizedlist">
	  <p class="para"><span class="file filename">lxc-usernet.conf</span> specifies how unprivileged
	  users may connect their containers to the host-owned network.</p>
	</li>
</ul></div>
    </p>
<p class="para">
      <span class="file filename">lxc.conf</span> and <span class="file filename">default.conf</span> are
      both under <span class="file filename">/etc/lxc</span> and <span class="file filename">$HOME/.config/lxc</span>,
      while <span class="file filename">lxc-usernet.conf</span> is only host-wide.
    </p>
<p class="para">
      By default, containers are located under /var/lib/lxc for the
      root user, and $HOME/.local/share/lxc otherwise.  The location
      can be specified for all lxc commands using the "-P|--lxcpath"
      argument.
    </p>
</div></div>
</div></div>
<div class="sect2 sect" id="lxc-network"><div class="inner">
<div class="hgroup"><h2 class="title">Networking</h2></div>
<div class="region"><div class="contents">
<p class="para">By default LXC creates a private network namespace for each container,
      which includes a layer 2 networking stack.  Containers usually connect to the
      outside world by either having a physical NIC or a veth tunnel endpoint passed
      into the container.  LXC creates a NATed bridge, lxcbr0, at host startup.
      Containers created using the default configuration will have one veth NIC
      with the remote end plugged into the lxcbr0 bridge.  A NIC can only exist
      in one namespace at a time, so a physical NIC passed into the container
      is not usable on the host.  </p>
<p class="para">It is possible to create a container without a private network namespace.
      In this case, the container will have access to the host networking like
      any other application.  Note that this is particularly dangerous if the
      container is running a distribution with upstart, like Ubuntu, since programs
      which talk to init, like <span class="cmd command">shutdown</span>, will talk over the
      abstract Unix domain socket to the host's upstart, and shut down the host.</p>
<p class="para">
      To give containers on lxcbr0 a persistent ip address based on domain name,
      you can write entries to <span class="file filename">/etc/lxc/dnsmasq.conf</span> like:
<div class="screen"><pre class="contents ">dhcp-host=lxcmail,10.0.3.100
dhcp-host=ttrss,10.0.3.101
</pre></div>
      </p>
<p class="para">If it is desirable for the container to be publicly accessible,
      there are a few ways to go about it.  One is to use <span class="cmd command">iptables</span>
      to forward host ports to the container, for instance

<div class="screen"><pre class="contents "> iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 587 -j DNAT \
 	--to-destination 10.0.3.100:587
 </pre></div>
      Another is to bridge the host's network interfaces (see the Ubuntu Server Guide's Network Configuration chapter,
      <a class="xref" href="network-configuration.html#bridging" title="Bridging">Bridging</a>).  Then, specify the host's bridge in the
      container configuration file in place of lxcbr0, for instance

<div class="screen"><pre class="contents ">lxc.network.type = veth
lxc.network.link = br0
</pre></div>
      Finally, you can ask LXC to use macvlan for the container's NIC.  Note that
      this has limitations and depending on configuration may not allow the
      container to talk to the host itself.  Therefore the other two options are
      preferred and more commonly used.</p>
<p class="para">There are several ways to determine the ip address for a container.
      First, you can use <span class="cmd command">lxc-ls --fancy</span> which will print the ip
      addresses for all running containers, or <span class="cmd command">lxc-info -i -H -n C1</span>
      which will print C1's ip address.  If dnsmasq is installed on the host, you can
      also add an entry to <span class="file filename">/etc/dnsmasq.conf</span> as follows
<div class="screen"><pre class="contents ">server=/lxc/10.0.3.1
</pre></div>
      after which dnsmasq will resolve C1.lxc locally, so that you can do:
<div class="screen"><pre class="contents ">ping C1
ssh C1
</pre></div>
      </p>
<p class="para">For more information, see the lxc.conf manpage as well as the example
      network configurations under <span class="file filename">/usr/share/doc/lxc/examples/</span>.
      </p>
</div></div>
</div></div>
<div class="sect2 sect" id="lxc-startup"><div class="inner">
<div class="hgroup"><h2 class="title">LXC startup</h2></div>
<div class="region"><div class="contents">
<p class="para">LXC does not have a long-running daemon.  However it does
       have three upstart jobs.</p>
<div class="list itemizedlist"><ul class="list itemizedlist">
<li class="list itemizedlist">
           <p class="para"><span class="file filename">/etc/init/lxc-net.conf:</span> is an
           optional job which only runs if <span class="file filename">
	   /etc/default/lxc-net</span> specifies USE_LXC_BRIDGE (true by
	   default). It sets up a NATed bridge for containers to
           use.</p>
         </li>
<li class="list itemizedlist">
           <p class="para"><span class="file filename">/etc/init/lxc.conf</span> loads the
	   lxc apparmor profiles and optionally starts any autostart
	   containers.  The autostart containers will be ignored if
	   LXC_AUTO (true by default) is set to true in
           <span class="file filename">/etc/default/lxc</span>.
	   See the lxc-autostart manual page for more information on
	   autostarted containers.
	   </p>
         </li>
<li class="list itemizedlist">
	  <p class="para"><span class="file filename">/etc/init/lxc-instance.conf</span>
	  is used by <span class="file filename">/etc/init/lxc.conf</span>
	  to autostart a container.
	  </p>
	 </li>
</ul></div>
</div></div>
</div></div>
<div class="sect2 sect" id="lxc-backinstores"><div class="inner">
<div class="hgroup"><h2 class="title">Backing Stores</h2></div>
<div class="region"><div class="contents">
<p class="para">LXC supports several backing stores for container root
	filesystems.  The default is a simple directory backing store,
	because it requires no prior host customization, so long as
	the underlying filesystem is large enough.  It also requires no root
	privilege to create the backing store, so that it is seamless for
	unprivileged use.  The rootfs for a privileged directory backed
	container is located (by default) under
	<span class="file filename">/var/lib/lxc/C1/rootfs</span>, while the rootfs for an
	unprivileged container is under
	<span class="file filename">~/.local/share/lxc/C1/rootfs</span>.  If a custom
	lxcpath is specified in lxc.system.com, then the container rootfs
	will be under <span class="file filename">$lxcpath/C1/rootfs</span>.
        </p>
<p class="para">
	A snapshot clone C2
	of a directory backed container C1 becomes an overlayfs backed
	container, with a rootfs called
	<span class="file filename">overlayfs:/var/lib/lxc/C1/rootfs:/var/lib/lxc/C2/delta0</span>.
	Other backing store types include loop, btrfs, LVM and zfs.
	</p>
<p class="para">
	A btrfs backed container mostly looks like a directory backed
	container, with its root filesystem in the same location.
	However, the root filesystem comprises a subvolume, so that a snapshot
	clone is created using a subvolume snapshot.
	</p>
<p class="para">The root filesystem for an LVM backed container can be any
	separate LV.  The default VG name can be specified in lxc.conf.
	The filesystem type and size are configurable per-container using
	lxc-create.
	</p>
<p class="para">
	The rootfs for a zfs backed container is a separate zfs filesystem,
	mounted under the traditional <span class="file filename">/var/lib/lxc/C1/rootfs</span>
	location.  The zfsroot can be specified at lxc-create, and a default
	can be specified in lxc.system.conf.
	</p>
<p class="para">  More information on creating containers with the
	various backing stores can be found in the lxc-create
	manual page.
	</p>
</div></div>
</div></div>
<div class="sect2 sect" id="lxc-templates"><div class="inner">
<div class="hgroup"><h2 class="title">Templates</h2></div>
<div class="region"><div class="contents">
<p class="para">
	Creating a container generally involves creating a root filesystem for
	the container.  <span class="cmd command">lxc-create</span> delegates this work to
	<span class="em emphasis">templates</span>, which are generally per-distribution.
	The lxc templates shipped with lxc can be found under
	<span class="file filename">/usr/share/lxc/templates</span>, and include templates
	to create Ubuntu, Debian, Fedora, Oracle, centos, and gentoo containers
	among others.
	</p>
<p class="para">
	Creating distribution images in most cases requires the ability to
	create device nodes, often requires tools which are not available
	in other distributions, and usually is quite time-consuming.  Therefore
	lxc comes with a special <span class="em emphasis">download</span> template,
	which downloads pre-built container images from a central lxc server.
	The most important use case is to allow simple creation of unprivileged
	containers by non-root users, who could not for instance easily run
	the <span class="cmd command">debootstrap</span> command.
	</p>
<p class="para">
	When running <span class="cmd command">lxc-create</span>, all options which come after
	<span class="em emphasis">--</span> are passed to the template.  In the
	following command, <span class="em emphasis">--name</span>, <span class="em emphasis">--template</span>
	and <span class="em emphasis">--bdev</span> are passed to <span class="cmd command">lxc-create</span>,
	while <span class="em emphasis">--release</span> is passed to the template:
<div class="screen"><pre class="contents "><span class="cmd command">
lxc-create --template ubuntu --name c1 --bdev loop -- --release bionic
</span>
</pre></div>
	</p>
<p class="para">
	You can obtain help for the options supported by any particular
	container by passing <span class="em emphasis">--help</span> and the template
	name to <span class="cmd command">lxc-create</span>.  For instance, for help with
	the download template,
	</p>
<div class="screen"><pre class="contents "><span class="cmd command">
lxc-create --template download --help
</span>
</pre></div>
</div></div>
</div></div>
<div class="sect2 sect" id="lxc-autostart"><div class="inner">
<div class="hgroup"><h2 class="title">Autostart</h2></div>
<div class="region"><div class="contents"><p class="para">LXC supports marking containers to be started at system boot.  Prior to
	Ubuntu 14.04, this was done using symbolic links under the directory
	<span class="file filename">/etc/lxc/auto</span>.  Starting with Ubuntu 14.04, it is done
	through the container configuration files.  An entry
<div class="screen"><pre class="contents "><span class="cmd command">
lxc.start.auto = 1
lxc.start.delay = 5
</span>
</pre></div>
	would mean that the container should be started at boot, and the system should
	wait 5 seconds before starting the next container.  LXC also supports ordering
	and grouping of containers, as well as reboot and shutdown by autostart groups.
	See the manual pages for lxc-autostart and lxc.container.conf for more information.
	</p></div></div>
</div></div>
<div class="sect2 sect" id="lxc-apparmor"><div class="inner">
<div class="hgroup"><h2 class="title">Apparmor</h2></div>
<div class="region">
<div class="contents">
<p class="para">LXC ships with a default Apparmor profile intended to protect the host
        from accidental misuses of privilege inside the container. For
        instance, the container will not be able to write to
        <span class="file filename">/proc/sysrq-trigger</span> or to most
        <span class="file filename">/sys</span> files.</p>
<p class="para">The <span class="file filename">usr.bin.lxc-start</span> profile is entered by
        running <span class="cmd command">lxc-start</span>. This profile mainly prevents
        <span class="cmd command">lxc-start</span> from mounting new filesystems outside of
        the container's root filesystem. Before executing the container's
        <span class="cmd command">init</span>, <span class="cmd command">LXC</span> requests a switch to
        the container's profile. By default, this profile is the
        <span class="file filename">lxc-container-default</span> policy which is defined in
        <span class="file filename">/etc/apparmor.d/lxc/lxc-default</span>. This profile
        prevents the container from accessing many dangerous paths, and from
        mounting most filesystems.</p>
<p class="para">Programs in a container cannot be further
	confined - for instance, MySQL runs under the container
	profile (protecting the host) but will not be able to enter the
	MySQL profile (to protect the container).</p>
<p class="para"><span class="cmd command">lxc-execute</span> does not enter an Apparmor
        profile, but the container it spawns will be confined.</p>
</div>
<div class="sect3 sect"><div class="inner">
<div class="hgroup"><h3 class="title">Customizing container policies</h3></div>
<div class="region"><div class="contents">
<p class="para">If you find that <span class="cmd command">lxc-start</span> is failing due to
        a legitimate access which is being denied by its Apparmor policy, you
        can disable the lxc-start profile by doing:</p>
<div class="screen"><pre class="contents ">sudo apparmor_parser -R /etc/apparmor.d/usr.bin.lxc-start
sudo ln -s /etc/apparmor.d/usr.bin.lxc-start /etc/apparmor.d/disabled/
</pre></div>
<p class="para">This will make <span class="cmd command">lxc-start</span> run unconfined, but
        continue to confine the container itself. If you also wish to disable
        confinement of the container, then in addition to disabling the
        <span class="file filename">usr.bin.lxc-start</span> profile, you must add:</p>
<div class="screen"><pre class="contents ">lxc.aa_profile = unconfined
</pre></div>
<p class="para">to the container's configuration file.</p>
<p class="para">
	LXC ships with a few alternate policies for containers.  If you
	wish to run containers inside containers (nesting), then you
	can use the lxc-container-default-with-nesting profile by adding
	the following line to the container configuration file
	<div class="screen"><pre class="contents ">lxc.aa_profile = lxc-container-default-with-nesting
	</pre></div>
	If you wish to use libvirt inside containers, then you will need
	to edit that policy (which is defined in
	<span class="file filename">/etc/apparmor.d/lxc/lxc-default-with-nesting</span>)
	by uncommenting the following line:
	<div class="screen"><pre class="contents ">mount fstype=cgroup -&gt; /sys/fs/cgroup/**,
	</pre></div>
	and re-load the policy.</p>
<p class="para">Note that the nesting policy with privileged containers is
	far less safe than the default policy, as it allows containers to
	re-mount <span class="file filename">/sys</span> and <span class="file filename">/proc</span>
	in nonstandard locations, bypassing apparmor protections.
	Unprivileged containers do not have this drawback since the
	container root cannot write to root-owned <span class="file filename">proc</span>
	and <span class="file filename">sys</span> files.
	</p>
<p class="para">Another profile shipped with lxc allows containers to mount
	block filesystem types like ext4.  This can be useful in some cases
	like maas provisioning, but is deemed generally unsafe since the superblock
	handlers in the kernel have not been audited for safe handling of
	untrusted input.</p>
<p class="para"> If you need to run a
        container in a custom profile, you can create a new profile under
        <span class="file filename">/etc/apparmor.d/lxc/</span>. Its name must start with
        <span class="file filename">lxc-</span> in order for <span class="cmd command">lxc-start</span> to
        be allowed to transition to that profile. The
        <span class="file filename">lxc-default</span> profile includes the re-usable
        abstractions file
        <span class="file filename">/etc/apparmor.d/abstractions/lxc/container-base</span>.
        An easy way to start a new profile therefore is to do the same, then
        add extra permissions at the bottom of your policy.</p>
<p class="para">After creating the policy, load it using:</p>
<div class="screen"><pre class="contents ">sudo apparmor_parser -r /etc/apparmor.d/lxc-containers
</pre></div>
<p class="para">The profile will automatically be loaded after a reboot, because
        it is sourced by the file
        <span class="file filename">/etc/apparmor.d/lxc-containers</span>. Finally, to make
        container <span class="file filename">CN</span> use this new
        <span class="file filename">lxc-CN-profile</span>, add the following line to its
        configuration file:</p>
<div class="screen"><pre class="contents ">lxc.aa_profile = lxc-CN-profile
</pre></div>
</div></div>
</div></div>
</div>
</div></div>
<div class="sect2 sect" id="lxc-cgroups"><div class="inner">
<div class="hgroup"><h2 class="title">Control Groups</h2></div>
<div class="region"><div class="contents">
<p class="para">Control groups (cgroups) are a kernel feature providing
        hierarchical task grouping and per-cgroup resource accounting and
        limits. They are used in containers to limit block and character
        device access and to freeze (suspend) containers. They can be further
        used to limit memory use and block i/o, guarantee minimum cpu shares,
        and to lock containers to specific cpus.
	</p>
<p class="para"> By default, a privileged container CN will be assigned to a cgroup
	called <span class="file filename">/lxc/CN</span>. In the case of name conflicts
	(which can occur when using custom lxcpaths) a suffix "-n", where n
	is an integer starting at 0, will be appended to the cgroup name.
	</p>
<p class="para"> By default, a privileged container CN will be assigned to a cgroup
	called <span class="file filename">CN</span> under the cgroup of the task which
	started the container, for instance
	<span class="file filename">/usr/1000.user/1.session/CN</span>. The container root
	will be given group ownership of the directory (but not all files)
	so that it is allowed to create new child cgroups.
	</p>
<p class="para">
	As of Ubuntu 14.04, LXC uses the cgroup manager (cgmanager) to
	administer cgroups. The cgroup manager receives D-Bus requests
	over the Unix socket <span class="file filename">/sys/fs/cgroup/cgmanager/sock</span>.
	To facilitate safe nested containers, the line
<div class="screen"><pre class="contents "><span class="cmd command">
lxc.mount.auto = cgroup
</span>
</pre></div>
	can be added to the container configuration causing the
	<span class="file filename">/sys/fs/cgroup/cgmanager</span> directory to be bind-mounted
	into the container. The container in turn should start the cgroup
	management proxy (done by default if the cgmanager package is installed
	in the container) which will move the <span class="file filename">/sys/fs/cgroup/cgmanager</span>
	directory to <span class="file filename">/sys/fs/cgroup/cgmanager.lower</span>, then
	start listening for requests to proxy on its own socket
	<span class="file filename">/sys/fs/cgroup/cgmanager/sock</span>. The host cgmanager
	will ensure that nested containers cannot escape their assigned cgroups
	or make requests for which they are not authorized.
	</p>
</div></div>
</div></div>
<div class="sect2 sect" id="lxc-cloning"><div class="inner">
<div class="hgroup"><h2 class="title">Cloning</h2></div>
<div class="region">
<div class="contents">
<p class="para">For rapid provisioning, you may wish to customize a canonical
        container according to your needs and then make multiple copies of it.
        This can be done with the <span class="cmd command">lxc-clone</span> program.
	</p>
<p class="para">Clones are either snapshots or copies of another container.
	A copy is a new container copied from the original, and takes as
	much space on the host as the original.  A snapshot exploits the
	underlying backing store's snapshotting ability to make a
	copy-on-write container referencing the first.  Snapshots can be
	created from btrfs, LVM, zfs, and directory backed containers.
	Each backing store has its own peculiarities - for instance, LVM
	containers which are not thinpool-provisioned cannot support snapshots
	of snapshots; zfs containers with snapshots cannot be removed until
	all snapshots are released;  LVM containers must be more carefully
	planned as the underlying filesystem may not support growing;
	btrfs does not suffer any of these shortcomings, but suffers from
	reduced fsync performance causing dpkg and apt to be slower.
	</p>
<p class="para">
	Snapshots of directory-packed containers are created using the
	overlay filesystem.  For instance, a privileged directory-backed
	container C1 will have its root filesystem under
	<span class="file filename">/var/lib/lxc/C1/rootfs</span>.  A snapshot clone of
	C1 called C2 will be started with C1's rootfs mounted readonly
	under <span class="file filename">/var/lib/lxc/C2/delta0</span>.  Importantly,
	in this case C1 should not be allowed to run or be removed while
	C2 is running.  It is advised instead to consider C1 a <span class="em emphasis">
	canonical</span> base container, and to only use its snapshots.
	</p>
<p class="para">
	Given an existing container called C1, a copy can be created using:</p>
<div class="screen"><pre class="contents "><span class="cmd command">
sudo lxc-clone -o C1 -n C2
</span>
</pre></div>
<p class="para">A snapshot can be created using:</p>
<div class="screen"><pre class="contents "><span class="cmd command">
sudo lxc-clone -s -o C1 -n C2
</span>
</pre></div>
<p class="para"> See the lxc-clone manpage for more information.</p>
</div>
<div class="sect3 sect"><div class="inner">
<div class="hgroup"><h3 class="title">Snapshots</h3></div>
<div class="region"><div class="contents">
<p class="para">To more easily support the use of snapshot clones for iterative
	  container development, LXC supports <span class="em emphasis">snapshots</span>.
	  When working on a container C1, before making a potentially dangerous
	  or hard-to-revert change, you can create a snapshot
<div class="screen"><pre class="contents "><span class="cmd command">
sudo lxc-snapshot -n C1
</span>
</pre></div>
	  which is a snapshot-clone called 'snap0' under /var/lib/lxcsnaps
	  or $HOME/.local/share/lxcsnaps.  The next snapshot will be called
	  'snap1', etc.  Existing snapshots can be listed using
	  <span class="cmd command">lxc-snapshot -L -n C1</span>, and a snapshot can be
	  restored - erasing the current C1 container - using
	  <span class="cmd command">lxc-snapshot -r snap1 -n C1</span>.  After the restore
	  command, the snap1 snapshot continues to exist, and the previous C1
	  is erased and replaced with the snap1 snapshot.
	  </p>
<p class="para">
	  Snapshots are supported for btrfs, lvm, zfs, and overlayfs containers.
	  If lxc-snapshot is called on a directory-backed container, an error
	  will be logged and the snapshot will be created as a copy-clone.  The
	  reason for this is that if the user creates an overlayfs snapshot of
	  a directory-backed container and then makes changes to the directory-backed
	  container, then the original container changes will be partially
	  reflected in the snapshot.  If snapshots of a directory backed container
	  C1 are desired, then an overlayfs clone of C1 should be created,
	  C1 should not be touched again, and the overlayfs clone can be edited
	  and snapshotted at will, as such
<div class="screen"><pre class="contents "><span class="cmd command">
lxc-clone -s -o C1 -n C2
lxc-start -n C2 -d # make some changes
lxc-stop -n C2
lxc-snapshot -n C2
lxc-start -n C2 # etc
</span>
</pre></div>
	  </p>
</div></div>
</div></div>
<div class="sect3 sect"><div class="inner">
<div class="hgroup"><h3 class="title">Ephemeral Containers</h3></div>
<div class="region"><div class="contents"><p class="para">While snapshots are useful for longer-term incremental development
	  of images, ephemeral containers utilize snapshots for quick, single-use
	  throwaway containers.  Given a base container C1, you can start an
	  ephemeral container using
<div class="screen"><pre class="contents "><span class="cmd command">
lxc-start-ephemeral -o C1
</span>
</pre></div>
	  The container begins as a snapshot of C1.  Instructions for logging into
	  the container will be printed to the console.  After shutdown, the ephemeral
	  container will be destroyed.  See the lxc-start-ephemeral manual page for
	  more options.
	  </p></div></div>
</div></div>
</div>
</div></div>
<div class="sect2 sect" id="lxc-hooks"><div class="inner">
<div class="hgroup"><h2 class="title">Lifecycle management hooks</h2></div>
<div class="region"><div class="contents">
<p class="para">Beginning with Ubuntu 12.10, it is possible to define hooks to
        be executed at specific points in a container's lifetime:</p>
<div class="list itemizedlist"><ul class="list itemizedlist">
<li class="list itemizedlist">
            <p class="para">Pre-start hooks are run in the host's namespace before the
            container ttys, consoles, or mounts are up. If any mounts are done
            in this hook, they should be cleaned up in the post-stop
            hook.</p>
          </li>
<li class="list itemizedlist">
            <p class="para">Pre-mount hooks are run in the container's namespaces, but
            before the root filesystem has been mounted. Mounts done in this
            hook will be automatically cleaned up when the container shuts
            down.</p>
          </li>
<li class="list itemizedlist">
            <p class="para">Mount hooks are run after the container filesystems have
            been mounted, but before the container has called
            <span class="cmd command">pivot_root</span> to change its root
            filesystem.</p>
          </li>
<li class="list itemizedlist">
            <p class="para">Start hooks are run immediately before executing the
            container's init. Since these are executed after pivoting into the
            container's filesystem, the command to be executed must be copied
            into the container's filesystem.</p>
          </li>
<li class="list itemizedlist">
            <p class="para">Post-stop hooks are executed after the container has been
            shut down.</p>
          </li>
</ul></div>
<p class="para">If any hook returns an error, the container's run will be
        aborted. Any <span class="em emphasis">post-stop</span> hook will still be
        executed. Any output generated by the script will be logged at the
        debug priority.</p>
<p class="para">Please see the lxc.container.conf manual page for the configuration file
        format with which to specify hooks. Some sample hooks are shipped with
        the lxc package to serve as an example of how to write and use such
        hooks.</p>
</div></div>
</div></div>
<div class="sect2 sect" id="lxc-consoles"><div class="inner">
<div class="hgroup"><h2 class="title">Consoles</h2></div>
<div class="region"><div class="contents">
<p class="para">Containers have a configurable number of consoles. One always
        exists on the container's <span class="file filename">/dev/console</span>. This is
        shown on the terminal from which you ran <span class="cmd command">lxc-start</span>,
        unless the <span class="em emphasis">-d</span> option is specified. The output on
        <span class="file filename">/dev/console</span> can be redirected to a file using
        the <span class="em emphasis">-c console-file</span> option to
        <span class="cmd command">lxc-start</span>. The number of extra consoles is
        specified by the <span class="cmd command">lxc.tty</span> variable, and is usually
        set to 4. Those consoles are shown on <span class="file filename">/dev/ttyN</span>
        (for 1 &lt;= N &lt;= 4). To log into console 3 from the host,
        use:</p>
<div class="screen"><pre class="contents "><span class="cmd command">
sudo lxc-console -n container -t 3
</span>
</pre></div>
<p class="para">or if the <span class="em emphasis">-t N</span> option is not specified, an
        unused console will be automatically chosen. To exit the console, use
        the escape sequence Ctrl-a q. Note that the escape sequence does not
        work in the console resulting from <span class="cmd command">lxc-start</span>
        without the <span class="em emphasis">-d</span> option.</p>
<p class="para">Each container console is actually a Unix98 pty in the host's
        (not the guest's) pty mount, bind-mounted over the guest's
        <span class="file filename">/dev/ttyN</span> and <span class="file filename">/dev/console</span>.
        Therefore, if the guest unmounts those or otherwise tries to access
        the actual character device <span class="cmd command">4:N</span>, it will not be
        serving getty to the LXC consoles. (With the default settings, the
        container will not be able to access that character device and getty
        will therefore fail.) This can easily happen when a boot script
        blindly mounts a new <span class="file filename">/dev</span>.</p>
</div></div>
</div></div>
<div class="sect2 sect" id="lxc-debugging"><div class="inner">
<div class="hgroup"><h2 class="title">Troubleshooting</h2></div>
<div class="region">
<div class="contents"></div>
<div class="sect3 sect"><div class="inner">
<div class="hgroup"><h3 class="title">Logging</h3></div>
<div class="region"><div class="contents"><p class="para"> If something goes wrong when starting a container, the first
	step should be to get full logging from LXC:
<div class="screen"><pre class="contents "><span class="cmd command">
sudo lxc-start -n C1 -l trace -o debug.out
</span>
</pre></div>
	This will cause lxc to log at the most verbose level, <span class="file filename">trace</span>,
	and to output log information to a file called 'debug.out'.  If the
	file <span class="file filename">debug.out</span> already exists, the new log
	information will be appended.
	</p></div></div>
</div></div>
<div class="sect3 sect" id="lxc-monitoring"><div class="inner">
<div class="hgroup"><h3 class="title">Monitoring container status</h3></div>
<div class="region"><div class="contents">
<p class="para">Two commands are available to monitor container state changes.
        <span class="cmd command">lxc-monitor</span> monitors one or more containers for any
        state changes. It takes a container name as usual with the
        <span class="em emphasis">-n</span> option, but in this case the container name
        can be a posix regular expression to allow monitoring desirable sets
        of containers. <span class="cmd command">lxc-monitor</span> continues running as it
        prints container changes. <span class="cmd command">lxc-wait</span> waits for a
        specific state change and then exits. For instance,</p>
<div class="screen"><pre class="contents "><span class="cmd command">
sudo lxc-monitor -n cont[0-5]*
</span>
</pre></div>
<p class="para">would print all state changes to any containers matching the
        listed regular expression, whereas</p>
<div class="screen"><pre class="contents "><span class="cmd command">
sudo lxc-wait -n cont1 -s 'STOPPED|FROZEN'
</span>
</pre></div>
<p class="para">will wait until container cont1 enters state STOPPED or state
        FROZEN and then exit.</p>
</div></div>
</div></div>
<div class="sect3 sect"><div class="inner">
<div class="hgroup"><h3 class="title">Attach</h3></div>
<div class="region"><div class="contents"><p class="para">
	As of Ubuntu 14.04, it is possible to attach to a container's
	namespaces.   The simplest case is to simply do
<div class="screen"><pre class="contents "><span class="cmd command">
sudo lxc-attach -n C1
</span>
</pre></div>
	which will start a shell attached to C1's namespaces, or,
	effectively inside the container.  The attach functionality is
	very flexible, allowing attaching to a subset of the container's
	namespaces and security context.  See the manual page for
	more information.
	</p></div></div>
</div></div>
<div class="sect3 sect"><div class="inner">
<div class="hgroup"><h3 class="title">Container init verbosity</h3></div>
<div class="region"><div class="contents"><p class="para">
	If LXC completes the container startup, but the container init
	fails to complete (for instance, no login prompt is shown),
	it can be useful to request additional verbosity from the
	init process.  For an upstart container, this might be:
<div class="screen"><pre class="contents "><span class="cmd command">
sudo lxc-start -n C1 /sbin/init loglevel=debug
</span>
</pre></div>
	You can also start an entirely different program in place of
	init, for instance
<div class="screen"><pre class="contents "><span class="cmd command">
sudo lxc-start -n C1 /bin/bash
sudo lxc-start -n C1 /bin/sleep 100
sudo lxc-start -n C1 /bin/cat /proc/1/status
</span>
</pre></div>
	</p></div></div>
</div></div>
</div>
</div></div>
<div class="sect2 sect" id="python-lxc"><div class="inner">
<div class="hgroup"><h2 class="title">LXC API</h2></div>
<div class="region"><div class="contents">
<p class="para">Most of the LXC functionality can now be accessed through an
      API exported by <span class="file filename">liblxc</span> for which bindings are
      available in several languages, including Python, lua, ruby, and go.
      </p>
<p class="para">
      Below is an example using the python bindings (which are available in the
      <span class="app application">python3-lxc</span> package) which creates and starts
      a container, then waits until it has been shut down:
      </p>
<div class="code"><pre class="contents "># sudo python3
Python 3.2.3 (default, Aug 28 2012, 08:26:03)
[GCC 4.7.1 20120814 (prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
&gt;&gt;&gt; import lxc
__main__:1: Warning: The python-lxc API isn't yet stable and may change at any p
oint in the future.
&gt;&gt;&gt; c=lxc.Container("C1")
&gt;&gt;&gt; c.create("ubuntu")
True
&gt;&gt;&gt; c.start()
True
&gt;&gt;&gt; c.wait("STOPPED")
True
</pre></div>
</div></div>
</div></div>
<div class="sect2 sect" id="lxc-security"><div class="inner">
<div class="hgroup"><h2 class="title">Security</h2></div>
<div class="region">
<div class="contents">
<p class="para">A namespace maps ids to resources. By not providing a container
      any id with which to reference a resource, the resource can be
      protected. This is the basis of some of the security afforded to
      container users. For instance, IPC namespaces are completely isolated.
      Other namespaces, however, have various <span class="em emphasis">leaks</span> which allow privilege to be
      inappropriately exerted from a container into another container or to
      the host.</p>
<p class="para">By default, LXC containers are started under a Apparmor policy to
      restrict some actions.
      The details of AppArmor integration with lxc are in section
      <a class="xref" href="lxc.html#lxc-apparmor" title="Apparmor">Apparmor</a>.  Unprivileged containers go further
      by mapping root in the container to an unprivileged host userid.  This
      prevents access to <span class="file filename">/proc</span> and <span class="file filename">/sys</span>
      files representing host resources, as well as any other files owned by root
      on the host.
      </p>
</div>
<div class="sect3 sect" id="lxc-seccomp"><div class="inner">
<div class="hgroup"><h3 class="title">Exploitable system calls</h3></div>
<div class="region"><div class="contents">
<p class="para">It is a core container feature that containers share a kernel
        with the host. Therefore if the kernel contains any exploitable system
        calls the container can exploit these as well. Once the container
        controls the kernel it can fully control any resource known to the
        host.</p>
<p class="para">Since Ubuntu 12.10 (Quantal) a container can also be constrained
        by a seccomp filter. Seccomp is a new kernel feature which filters the
        system calls which may be used by a task and its children. While
        improved and simplified policy management is expected in the near
        future, the current policy consists of a simple whitelist of system
        call numbers. The policy file begins with a version number (which must
        be 1) on the first line and a policy type (which must be 'whitelist')
        on the second line. It is followed by a list of numbers, one per
        line.</p>
<p class="para">In general to run a full distribution container a large number
        of system calls will be needed. However for application containers it
        may be possible to reduce the number of available system calls to only
        a few. Even for system containers running a full distribution security
        gains may be had, for instance by removing the 32-bit compatibility
        system calls in a 64-bit container. See the lxc.container.conf manual
	page for details of how to configure a container
        to use seccomp. By default, no seccomp policy is loaded.</p>
</div></div>
</div></div>
</div>
</div></div>
<div class="sect2 sect" id="lxc-resources"><div class="inner">
<div class="hgroup"><h2 class="title">Resources</h2></div>
<div class="region"><div class="contents"><div class="list itemizedlist"><ul class="list itemizedlist">
<li class="list itemizedlist">
          <p class="para">The DeveloperWorks article <a href="https://www.ibm.com/developerworks/linux/library/l-lxc-containers/" class="ulink" title="https://www.ibm.com/developerworks/linux/library/l-lxc-containers/">LXC:
          Linux container tools</a> was an early introduction to the use
          of containers.</p>
        </li>
<li class="list itemizedlist">
          <p class="para">The <a href="http://www.ibm.com/developerworks/linux/library/l-lxc-security/index.html" class="ulink" title="http://www.ibm.com/developerworks/linux/library/l-lxc-security/index.html">
          Secure Containers Cookbook</a> demonstrated the use of security
          modules to make containers more secure.</p>
        </li>
<li class="list itemizedlist">
          <p class="para">Manual pages referenced above can be found at:</p>
          <div class="screen"><pre class="contents "><a href="http://manpages.ubuntu.com/manpages/en/man7/capabilities.7.html" class="ulink" title="http://manpages.ubuntu.com/manpages/en/man7/capabilities.7.html">capabilities</a>
<a href="http://manpages.ubuntu.com/manpages/en/man5/lxc.conf.5.html" class="ulink" title="http://manpages.ubuntu.com/manpages/en/man5/lxc.conf.5.html">lxc.conf</a>
</pre></div>
        </li>
<li class="list itemizedlist">
          <p class="para">The upstream LXC project is hosted at <a href="http://linuxcontainers.org" class="ulink" title="http://linuxcontainers.org">linuxcontainers.org</a>.</p>
        </li>
<li class="list itemizedlist">
          <p class="para">LXC security issues are listed and discussed at <a href="http://wiki.ubuntu.com/LxcSecurity" class="ulink" title="http://wiki.ubuntu.com/LxcSecurity">the LXC Security wiki
          page</a></p>
        </li>
<li class="list itemizedlist">
          <p class="para">For more on namespaces in Linux, see: S. Bhattiprolu, E. W.
          Biederman, S. E. Hallyn, and D. Lezcano. Virtual Servers and Check-
          point/Restart in Mainstream Linux. SIGOPS Operating Systems
          Review, 42(5), 2008.</p>
        </li>
</ul></div></div></div>
</div></div>
</div>
<div class="links nextlinks">
<a class="nextlinks-prev" href="lxd.html" title="LXD">Previous</a><a class="nextlinks-next" href="clustering.html" title="Clustering">Next</a>
</div>
<div class="clear"></div>
</div>
<div id="pagebottom"></div>
</div></div>
</div>
<div id="footer"><p>The material in this document is available under a free license, see <a href="https://help.ubuntu.com/legal.html">Legal</a> for details.<br>
          For information on contributing see the <a href="https://wiki.ubuntu.com/DocumentationTeam">Ubuntu Documentation Team wiki page</a>.
          To report errors in this serverguide documentation, <a href="https://bugs.launchpad.net/serverguide">file a bug report</a>.</p></div>
</div>
</body>
</html>
